Amazon FSx for NetApp ONTAPにデータ移行をするときはキャパシティプールストレージを有効的に使おう
あまりアクセスしないデータをプライマリストレージに置くのはもったいない
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSx for ONTAP)にデータ移行をするときにプライマリストレージに一旦データを配置するのがもったいないと思ったことはありますか? 私はあります。
以下記事で紹介している通り、FSx for ONTAPにはSSDのプライマリストレージと、オブジェクトストレージのキャパシティプールストレージの2種類があります。
性能としてはプライマリストレージの方が良いですが、料金的にはキャパシティプールストレージの方が安いです。
2022/9/24時点のSingle-AZでデータ圧縮や重複排除を有効化した場合のそれぞれの料金は以下の通りです。
- プライマリストレージ : 毎月 0.0525 USD/GB
- キャパシティプールストレージ : 毎月 0.0083USD/GB
キャパシティプールストレージの保存料金はプライマリストレージの16%程であることが分かります。
キャパシティプールストレージには読み込みリクエストと書き込みリクエストでそれぞれ追加で料金が発生しますが、それを差し引いても安いと思います。
以上を踏まえて、既存のファイルサーバーからFSx for ONTAPに移行するケースを考えます。
一般的なファイルサーバーであれば、全てのファイルが常に高速な読み書きが求められることは少ないと考えます。場合によってはアーカイブ目的でファイルサーバーに保存しているファイルもあるでしょう。そのようなケースでは、移行時に全てのファイルをプライマリストレージに保存するのはもったいないと考えます。
100TBのファイルサーバーを移行する際、その内アクティブなファイルは100GBしかないのにFSx for ONTAPのストレージキャパシティ(プライマリストレージ)を100TBプロビジョニングするのはコスト的によろしくないですよね。
対処案としてはFSx for ONTAPのボリュームの階層化ポリシーをALLにすることが挙げられます。FSx for ONTAPのボリュームの階層化ポリシーをALLにするとスナップショットとユーザーデータブロックがキャパシティプールストレージに移動されます。こうすることでなるべくプライマリストレージを使用せずに移行することができます。
そして、移行が完了したら階層化ポリシーをAUTOに変更して、読み込みがあったブロックは高速なプライマリストレージに移動させるといった運用も可能です。
階層化ポリシーをALLにする場合、以下ポイントが気になると思います。
- 書き込んだデータは一旦プライマリストレージを経由するのか、それともキャパシティプールストレージに直接書き込まれるのか
- 一旦プライマリストレージを経由するのであれば、プロビジョニングしたプライマリストレージの以上の書き込みがあった場合は、どのような挙動をするのか
- キャパシティプールストレージに直接書き込まれるのであれば、プライマリストレージとして比較して速度はどの程度なのか
以上のポイントを検証してみます。
なお、AWS公式ブログでも同じような検証をしています。併せてご覧ください。
いきなりまとめ
- 階層化ポリシーを
ALLにした場合も、一旦プライマリストレージを経由してキャパシティプールストレージに書き込まれる - 階層化ポリシーを
ALLにした場合、プライマリストレージのサイズ以上のデータを一気に書き込みと、データが溢れる可能性がある - 対応として帯域制限をかけるなどフォローが必要
- DataSyncの帯域制御
- SnapMirrorの帯域制御
- ONTAPのQoS機能
- なるべく移行したい場合には、FSx for ONTAPのスループットキャパシティをより高性能なものに変更し、プライマリストレージからキャパシティプールストレージへの書き込み時の帯域制限をかかりにくくするアプローチもある
- 階層化ポリシーが
ALLだとポストプロセス重複排除が効きづらいので注意が必要
検証環境
検証環境は以下の通りです。
階層化ポリシーを変更して、それぞれどのような挙動をするのか確認していきます。
リソースは全てAWS CDKでデプロイします。以下記事の検証で使用したコードを再利用しています。
リポジトリはこちらです。
再利用するにあたって、ボリュームサイズと階層化ポリシーを変更しています。
// FSX for ONTAP volume
const volumeName = "fsx_for_ontap_volume_nfs";
const junctionPath = "/nfs";
new fsx.CfnVolume(this, "NFS Volume", {
name: volumeName,
ontapConfiguration: {
junctionPath,
sizeInMegabytes: "2097152",
storageEfficiencyEnabled: "true",
storageVirtualMachineId: svm.ref,
securityStyle: "UNIX",
tieringPolicy: {
name: "NONE",
},
},
tags: [
{
key: "Name",
value: "fsx_for_ontap_volume_nfs",
},
],
volumeType: "ONTAP",
});
また、スループットキャパシティを128 MB/sから256 MB/sに変更しています。
// FSx for ONTAP file system
const fsxForOntapFileSystem = new fsx.CfnFileSystem(
this,
"FSx for ONTAP file system",
{
fileSystemType: "ONTAP",
subnetIds: vpc.selectSubnets({
subnetType: ec2.SubnetType.PRIVATE_ISOLATED,
}).subnetIds,
ontapConfiguration: {
deploymentType: "SINGLE_AZ_1",
automaticBackupRetentionDays: 7,
dailyAutomaticBackupStartTime: "16:00",
diskIopsConfiguration: {
mode: "AUTOMATIC",
},
throughputCapacity: 256,
weeklyMaintenanceStartTime: "6:17:00",
},
securityGroupIds: [fileSystemSecurityGroup.securityGroupId],
storageCapacity: 1024,
storageType: "SSD",
tags: [
{
key: "Name",
value: "fsx-for-ontap-file-system-single-az",
},
],
}
);
階層化ポリシーをNONEにした場合の書き込み速度の確認
それでは、階層化ポリシーをNONEにした場合の書き込み速度の確認からしていきます。
まず、階層化ポリシーがNONEになっているかボリュームの情報を確認します。
# FSx for ONTAPのボリュームのID
$ volume_id=fsvol-06aa78649dce116f8
# ボリュームの情報確認
$ aws fsx describe-volumes \
--volume-id "$volume_id"
{
"Volumes": [
{
"CreationTime": "2022-09-24T05:04:28.226000+00:00",
"FileSystemId": "fs-0c6a3b2f825a9c21b",
"Lifecycle": "CREATED",
"Name": "fsx_for_ontap_volume_nfs",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/nfs",
"SecurityStyle": "UNIX",
"SizeInMegabytes": 2097152,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0e896ca62e3b55b5f",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "66f7d25d-3bc6-11ed-8f66-c37d61d15491",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0c6a3b2f825a9c21b/fsvol-06aa78649dce116f8",
"VolumeId": "fsvol-06aa78649dce116f8",
"VolumeType": "ONTAP"
}
]
}
階層化ポリシーがNONEになっていますね。
それでは、EC2インスタンスからファイルを書き込んで速度を確認してみます。
$ df -hT Filesystem Type Size Used Avail Use% Mounted on devtmpfs devtmpfs 471M 0 471M 0% /dev tmpfs tmpfs 479M 0 479M 0% /dev/shm tmpfs tmpfs 479M 352K 478M 1% /run tmpfs tmpfs 479M 0 479M 0% /sys/fs/cgroup /dev/nvme0n1p1 xfs 8.0G 1.6G 6.4G 20% / svm-0e896ca62e3b55b5f.fs-0c6a3b2f825a9c21b.fsx.us-east-1.amazonaws.com:/nfs nfs4 2.0T 1.1T 854G 57% /mnt/fsx $ sudo dd if=/dev/urandom of=/mnt/fsx/testfile_1 bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 41.6307 s, 258 MB/s $ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-0e896ca62e3b55b5f.fs-0c6a3b2f825a9c21b.fsx.us-east-1.amazonaws.com:/nfs 2.0T 1.1T 844G 57% /mnt/fsx $ ls -l /mnt/fsx total 10527052 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:08 testfile_1
書き込み速度は258 MB/sでした。
スループットキャパシティを256 MB/sに設定したなので、大体指定した通りですね。
なお、スループットキャパシティの値がパフォーマンス与える影響は以下AWS公式ドキュメントをご覧ください。
プライマリストレージとキャパシティプールストレージの使用量の推移もCloudWatch メトリクスから確認してみましょう。
書き込み始めたタイミングでプライマリストレージの使用量の青いグラフが上昇しています。一方でキャパシティプールストレージの使用量のオレンジのグラフは変動していないですね。
階層化ポリシーをALLにした場合の書き込み速度
それでは階層化ポリシーをALLにした場合の書き込み速度を確認してみます
まず、階層化ポリシーをALLに変更します。
# 階層化ポリシーを ALL に変更
$ aws fsx update-volume \
--volume-id "$volume_id" \
--ontap-configuration TieringPolicy={Name=ALL}
{
"Volume": {
"CreationTime": "2022-09-24T05:04:28.226000+00:00",
"FileSystemId": "fs-0c6a3b2f825a9c21b",
"Lifecycle": "CREATED",
"Name": "fsx_for_ontap_volume_nfs",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/nfs",
"SecurityStyle": "UNIX",
"SizeInMegabytes": 2097152,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0e896ca62e3b55b5f",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "NONE"
},
"UUID": "66f7d25d-3bc6-11ed-8f66-c37d61d15491",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0c6a3b2f825a9c21b/fsvol-06aa78649dce116f8",
"VolumeId": "fsvol-06aa78649dce116f8",
"VolumeType": "ONTAP"
}
}
# 階層化ポリシーが ALL に変更されたことを確認
$ aws fsx describe-volumes \
--volume-id "$volume_id"
{
"Volumes": [
{
"CreationTime": "2022-09-24T05:04:28.226000+00:00",
"FileSystemId": "fs-0c6a3b2f825a9c21b",
"Lifecycle": "CREATED",
"Name": "fsx_for_ontap_volume_nfs",
"OntapConfiguration": {
"FlexCacheEndpointType": "NONE",
"JunctionPath": "/nfs",
"SecurityStyle": "UNIX",
"SizeInMegabytes": 2097152,
"StorageEfficiencyEnabled": true,
"StorageVirtualMachineId": "svm-0e896ca62e3b55b5f",
"StorageVirtualMachineRoot": false,
"TieringPolicy": {
"Name": "ALL"
},
"UUID": "66f7d25d-3bc6-11ed-8f66-c37d61d15491",
"OntapVolumeType": "RW"
},
"ResourceARN": "arn:aws:fsx:us-east-1:<AWSアカウントID>:volume/fs-0c6a3b2f825a9c21b/fsvol-06aa78649dce116f8",
"VolumeId": "fsvol-06aa78649dce116f8",
"VolumeType": "ONTAP"
}
]
}
この状態で書き込みをしてみます。
$ sudo dd if=/dev/urandom of=/mnt/fsx/testfile_2 bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 42.0757 s, 255 MB/s $ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-0e896ca62e3b55b5f.fs-0c6a3b2f825a9c21b.fsx.us-east-1.amazonaws.com:/nfs 2.0T 1.1T 834G 58% /mnt/fsx $ ls -l /mnt/fsx total 21054104 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:08 testfile_1 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:13 testfile_2
書き込み速度は255 MB/sと、階層化ポリシーがALLの場合でもさほど変わりませんでした。
それでは、プライマリストレージとキャパシティプールストレージのサイズの推移もCloudWatch メトリクスから確認してみます。
書き込み始めたタイミングでプライマリストレージの使用量の青いグラフが上昇し、その後下降しています。そして、下降したタイミングでキャパシティプールストレージの使用量のオレンジのグラフは上昇しています。
以上のことから書き込み処理は一旦プライマリストレージを経由するようですね。
プライマリストレージのサイズ以上の書き込みをしてみる
それでは、プライマリストレージのサイズ以上の書き込みをしてしまった場合、どのような挙動をするのか確認してみましょう
プライマリストレージは1024GBでプロビジョニングしています。この状態で1.1TB(1126.4GB)のファイルを作成してみます。
$ df -hT | grep nfs4 svm-0e896ca62e3b55b5f.fs-0c6a3b2f825a9c21b.fsx.us-east-1.amazonaws.com:/nfs nfs4 2.9T 2.1T 855G 71% /mnt/fsx $ sudo dd if=/dev/urandom of=/mnt/fsx/testfile_3 bs=1M count=1153434
はい、途中でSSMセッションマネージャーのセッションが切れてしまいました。
再接続してどの程度書き込んだのか確認してみます。
$ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-0e896ca62e3b55b5f.fs-0c6a3b2f825a9c21b.fsx.us-east-1.amazonaws.com:/nfs 2.0T 1.1T 851G 57% /mnt/fsx $ ls -l /mnt/fsx/ total 177572580 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:08 testfile_1 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:13 testfile_2 -rw-r--r-- 1 nobody nobody 159646384128 Sep 24 05:43 testfile_3
どうやら150GBほど書き込んだようですね。
それでは、プライマリストレージとキャパシティプールストレージのサイズの推移もCloudWatch メトリクスから確認してみます。
キャパシティプールストレージの使用量のオレンジのグラフは書き込みが開始したタイミングで緩やかに上昇していきます。プライマリストレージの使用量の青いグラフがほぼ平行線になったタイミングでも上昇量を続けていました。
一方、プライマリストレージの使用量の青いグラフは書き込み始めたタイミングで上昇しますが、あるタイミングでほぼ平行線になります。そして、徐々に下降していき、最後はほぼ0となりました。
この挙動はもしや...と思い、EC2インスタンスのCPU使用率を確認すると、明らかに元気がないです。
t3.microで検証していたのでバーストクレジットを使い切ったようですね。
インスタンスタイプをc6i.largeに変更して再チャレンジしてみます。
# 途中で書き込みが終了してしまったテストファイルを削除 $ sudo rm -f /mnt/fsx/testfile_3 $ ls -l /mnt/fsx/ total 21054104 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:08 testfile_1 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:13 testfile_2 $ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-0e896ca62e3b55b5f.fs-0c6a3b2f825a9c21b.fsx.us-east-1.amazonaws.com:/nfs 2.0T 1.1T 850G 57% /mnt/fsx $ sudo dd if=/dev/urandom of=/mnt/fsx/testfile_3 bs=1M count=1153434
またしても、途中でSSMセッションマネージャーのセッションが切れてしまいました。
再接続してどの程度書き込んだのか確認してみます。
$ df -ht nfs4 Filesystem Size Used Avail Use% Mounted on svm-0e896ca62e3b55b5f.fs-0c6a3b2f825a9c21b.fsx.us-east-1.amazonaws.com:/nfs 2.0T 1.3T 647G 67% /mnt/fsx $ ls -l /mnt/fsx/ total 338841260 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:08 testfile_1 -rw-r--r-- 1 nobody nobody 10737418240 Sep 24 05:13 testfile_2 -rw-r--r-- 1 nobody nobody 324137910272 Sep 24 06:28 testfile_3
300GBほど書き込んだようですね。
それでは、プライマリストレージとキャパシティプールストレージのサイズの推移もCloudWatch メトリクスから確認してみます。
初めの方はキャパシティプールストレージの使用量のオレンジのグラフの上昇量が高いですが、徐々にプライマリストレージの使用量の青いグラフの方が上昇していきます。
終盤に差し掛かると完全にプライマリストレージからキャパシティプールストレージへの書き込み速度よりも、EC2インスタンスからプライマリストレージへの書き込み速度の方が上回っていることが分かります。
そして、書き込みが終わったタイミングで一気にプライマリストレージの使用量の青いグラフが下降し、キャパシティプールストレージの使用量のオレンジが上昇することから、プライマリストレージからキャパシティプールストレージへの書き込みが一斉に進んだことが分かります。
FSxのコンソールからFSx for ONTAPファイルシステムの使用可能なプライマリストレージ容量というグラフも見てみましょう。
途中から一気に使用可能な領域が減っていることが分かります。
恐らく、このまま書き込みを進めていたら、空き容量不足により書き込みが途中で終了していたと予想します。
対応策
対応策としてはQoSで帯域を制限することが挙げられます。
具体的にはプライマリストレージからキャパシティプールストレージへの書き込み速度よりも、プライマリストレージへの書き込み速度が上回らないようにします。
AWS公式ブログでは、DataSyncの帯域幅制限を使用してコントロールする例を紹介しています。
抜粋 : Migrating file shares to Amazon FSx for NetApp ONTAP using AWS DataSync | AWS Storage Blog
DataSyncはこのAWS公式ブログで紹介されている通り、タスク実行中でも帯域幅の制限を変更することができます。
CloudWatchアラームとEventBridge、Step Functionsを組み合わせて、「プライマリストレージの空き容量がある値を下回ったらUpdateTaskExecution APIでDataSyncタスクの帯域幅を絞る」ような処理を実装しても良さそうですね。
SnapMirrorで移行する場合は、Throttleで帯域制御することも可能です。
[-k, -throttle ] - Throttle (KB/sec)
This optional parameter limits the network bandwidth used for transfers. It configures for the relationship the maximum rate (in Kbytes/sec) at which data can be transferred. If no throttle is configured, by default the SnapMirror relationship fully utilizes the network bandwidth available. You can also configure the relationship to fully use the network bandwidth available by explicitly setting the throttle to unlimited or 0 . The minimum effective throttle value is four Kbytes/sec, so if you specify a throttle value between 1 and 4 , it will be treated as 4 . For FlexGroup volume relationships, the throttle value is applied individually to each constituent relationship. The -throttle parameter does not affect load-sharing mirrors and other SnapMirror relationships with "Relationship Capability" of "Pre 8.2" confined to a single cluster.
それ以外DataSyncやSnapMirror以外の場合は、FSx for ONTAPのQoSの機能を使うのも良いと思います。
ボリュームやファイル、LUNなどの単位でQoSの設定が可能です。設定する場合、スループットの上限を指定するQoS Maxを設定することになります。
また、帯域制限は最小限にして、なるべく移行したい場合には、FSx for ONTAPのスループットキャパシティをより高性能なものに変更し、プライマリストレージからキャパシティプールストレージへの書き込み時の帯域制限をかかりにくくするアプローチもあります。
こちらの場合は当然ながらコストに跳ねてくるので注意が必要です。なお、スループットキャパシティ変更時にワークロードの中断は発生しませんが、内部的にはSVM間でフェイルオーバー/フェイルバックが発生します。
プライマリストレージの空き容量には常に気をつけよう
Amazon FSx for NetApp ONTAPにデータ移行をする際はキャパシティプールストレージを有効的に使い、プライマリストレージの使用量を節約することを紹介しました。
キャパシティプールストレージを有効活用することで、FSx for ONTAPのコストを削減することができます。
また、階層化ポリシーがALLの場合であっても一旦プライマリストレージを経由してキャパシティプールストレージに書き込まれるのがポイントでした。
プライマリストレージ以上のデータを書き込む場合は、キャパシティプールストレージにデータが流れていっているか、プライマリストレージの空き容量に余裕があるかを常にウォッチしておきましょう。
2023/1/19 追記 : 階層化ポリシーがALLだとポストプロセス重複排除が効きづらいので注意が必要です。以下記事で検証しているので合わせてご覧ください。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[レポート]AWSのデータ取り込み戦略 - Solving different data ingestion use cases with AWS (ANT330) #AWSreInvent](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
